The process of booting a computing device prepares the computing device to perform useful tasks under control of an operating system. The initial application of power to the electronic circuitry of a computing device generally only renders the computing device capable of performing rudimentary tasks, such as fetching instructions embedded into hardware components of the computing device. Thus, the boot process executes those instructions, and initiates processes that enable a computing device to perform more complex tasks. However, because the boot process performs operations prior to the execution of the operating system and any other software whose execution utilizes the operating system, malicious code executed during the boot process can remain undetected but can affect the ongoing execution properties of the system.
To provide protection against malicious code, the notion of a “trusted computer” was developed whereby the state of the computing device could be ascertained. To that end, a “Trusted Platform Module” (TPM) chip was added to the computing device, which could maintain values in a secure manner and, thereby, be used to ascertain if the computer had booted properly. In particular, the TPM chip comprises registers known as “Platform Configuration Registers” (PCRs) that store values that uniquely identify measurements of the system that have been taken since power was applied to the circuitry of the computing device. These measurements are indicative of the software that is executed during the boot process and of the presence and configuration of various hardware components. If the proper measurements were made in the correct order, then the PCRs of the TPM would contain values that could be used to verify that the computing device did indeed boot in a recognizable way. If the measurements are recognized to represent a computer that has booted in a trusted way, then the machine is in a trusted state when it begins executing the operating system software. In such a manner, malicious code in the boot sequence can be detected.
The measurements that are made during the boot process, and the resulting values stored in the PCRs of the TPM, can define the trust state of the machine. As such, those PCR values can be utilized as part of the “attestation” and “sealing” mechanisms that can be performed by the TPM. “Attestation” generally refers to the provision of signed versions of one or more PCR values to an external entity so as to prove that the computing device is in a trusted state. Specifically, one or more PCR values are signed by the TPM using its private key and then transmitted to an external entity. The external entity can verify that the PCR values did indeed come from the indicated computing device, based on the fact that the PCR values were signed with the TPM's private key, and can further verify, based on the values of the PCRs themselves, that the computing device was placed into a trusted state. “Sealing”, on the other hand, refers to the retention of a secret, by the TPM, which should only be released by the TPM if the values of relevant PCRs are the same as they were when the secret was provided to the TPM to be “sealed.”
Unfortunately, not all measurements taken during the booting of a computing device comprise an equivalent security risk. Thus, using the TPM to verify all of the instructions executed during the booting of a computing device can complicate the evaluation of the trusted state of the computing device beyond what it reasonably needs to be. As a result, deviations that would otherwise be insignificant can, instead, result in a determination that the computing device is not in a trusted state. For example, the order in which some components are executed may be irrelevant and, consequently, there may not exist a precise control mechanism by which their execution order is controlled. If the order in which such components are executed changes, the values of one or more PCRs, as maintained by the TPM, may likewise change. As a result, secrets that were sealed by the TPM based on a particular set of PCR values will now no longer be unsealed, even though the state of the computing device has not materially changed. Similarly, attestation to an external entity may also fail, since the PCR values attested to by the TPM differ from those believed, by the external entity, to be indicative of a trusted state of the computing device.
As described above, the mechanisms of attestation and sealing are “fragile” because they can easily cause secrets to remain sealed, or computing devices to be found not in a trusted state, despite no valid security reason for doing so. To provide more rigorous attestation and sealing mechanisms, the concepts of “generalized attestation” and “generalized sealing” have been developed. Unlike the sealing described above, generalized sealing does not seal a secret to a precise and immutable set of PCR values, but rather seals the secret to one or more policies that can be verified through a range of PCR values. Similarly, unlike the attestation described above, generalized attestation enables the trusted state of a computing device to be verified by reference to one or more policies that can be expressed via a range of PCR values.
In the generalized attestation and generalized sealing mechanisms, logs of hashes are referenced, rather than individual PCR values. More specifically, in addition to, or as an alternative to, maintaining the PCR values in the manner described above, the TPM can also maintain one or more lists, or logs, of values uniquely identifying each component of the computing device that was utilized or executed during the boot process. Typically such uniquely identifying values will be hash values obtained by hashing some or all of the component utilized or executed.
During the generalized attestation and generalized sealing mechanisms, these logs of hashes are simplified and then referenced according to one or more policies. In particular, larger systems, such as an operating system, or a set of graphics drivers can comprise multiple components. When referencing the log of hashes of components utilized or executed during the boot process, the hash value of a component known to be part of a larger system, such as an operating system, or a set of graphics drivers, can be replaced by an identifier of the larger system, such as the name of the operating system or the set of graphics drivers. Ultimately, the log of hashes of components utilized or executed during the boot process can be pared down to a list comprising multiple entries identifying larger systems, such as an operating system or a set of graphics drivers and some, or possibly even no, hashes. Generalized attestation and generalized sealing can then be performed based on whether the few, or no, remaining hashes, and the listed larger systems, are trusted. Because individual components of larger systems are ultimately pared down to merely an indication of the larger system, the precise order of execution of each of those components during the boot process need not influence the determination of whether the computing device is in a trusted state.
Unfortunately, TPMs represent a hardware cost to the manufacturer of the computing device that the manufacturer cannot easily recoup. Consequently, manufacturers have selected very inexpensive TPMs that comprise very little computational ability, as compared to modern processors and other processing components of a computing device. In particular, the inexpensive TPMs selected do not comprise sufficient computational ability to perform a policy-based evaluation of a log of hashes of components utilized or executed during the boot process. Consequently, the hardware TPM cannot, by itself, perform the TPM-specific portions of either the generalized attestation mechanisms or the generalized sealing mechanisms.